-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: cypress testing #17
Conversation
You have some conflicts |
# Conflicts: # .env.example # .github/workflows/build.yml # .github/workflows/cloudflare-deploy.yml
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool stuff. Reviewed from my phone.
let issue1: Record<string, unknown>; | ||
let issue2: Record<string, unknown>; | ||
let loginToken: Record<string, unknown>; | ||
let githubUser: Record<string, unknown>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Try setting all the correct types by importing them
Check this example https://github.com/ubiquity/github-labels-processor/blob/5f3921da1fa944d340cd375c3dfc4503531ebee5/src/github-types.ts
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can do. I didn't bother because they are populated from a string, so type checking is not relevant as I don't manipulate them. Will change it
}); | ||
|
||
it("User can log in", () => { | ||
cy.intercept("https://api.github.com/repos/*/*/issues**", (req) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you are intercepting everything doesn't that kill the point of the test? Why don't we do real end-to-end tests? What if Supabase is broken and we can't oauth etc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we don't develop the other end (eg the backend) I didn't think it was relevant to test it. If GitHub backend breaks there is nothing we can do. The proper way to handle that would be to have BE error test cases, and to have a health check running on the production instance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay sounds smart I'm in. You can file some issues for this with sufficient details so we can get around to it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You mean an issue mentioning the creation of e2e testing with the real endpoint correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The proper way as you say
Just be sure to handle the unresolved comments @FernandVEYRIER |
Resolves #14